A pattern language is an organized and coherent set of patterns, each of which describes a problem and the core of a solution that can be used in many ways within a specific field of expertise. The term was coined by architect Christopher Alexander and popularized by his 1977 book A Pattern Language.
A pattern language can also be an attempt to express the deeper wisdom of what brings aliveness within a particular field of human endeavor, through a set of interconnected patterns. Aliveness is one placeholder term for "the quality that has no name": a sense of wholeness, spirit, or grace, that while of varying form, is precise and empirically verifiable.
Elemental or universal patterns such as "door" or "partnership" are versatile ideals of design, either as found in experience or for use as components in practice, explicitly described as holistic resolutions of the forces in recurrent contexts and circumstances, whether in architecture, medicine, software development or governance, etc. Patterns might be invented or found and studied, such as the naturally occurring patterns of design that characterize human environments.Henshaw, J. Guiding Patterns of Naturally Occurring Design: Elements. PURPLSOC 2015 proceedings, July 3-5 2015 Krems, Austria PURPLSOC meeting on the many open scientific questions, e.g. regarding the theoretical background of patterns and the practical implementation of pattern methods in research and teaching.
Like all languages, a pattern language has vocabulary, syntax, and grammar – but a pattern language applies to some complex activity other than communication. In pattern languages for design, the parts break down in this way:
This simplifies the design work because designers can start the process from any part of the problem they understand and work toward the unknown parts. At the same time, if the pattern language has worked well for many projects, there is reason to believe that even a designer who does not completely understand the design problem at first will complete the design process, and the result will be usable. For example, skiers coming inside must shed snow and store equipment. The messy snow and boot cleaners should stay outside. The equipment needs care, so the racks should be inside.
The actual organizational structure (Hierarchy, Iterative method, etc.) is left to the discretion of the designer, depending on the problem. This explicitly lets a designer explore a design, starting from some small part. When this happens, it's common for a designer to realize that the problem is actually part of a larger solution. At this point, the design almost always becomes a better design.
In the language, therefore, each pattern has to indicate its relationships to other patterns and to the language as a whole. This gives the designer using the language a great deal of guidance about the related problems that must be solved.
The most difficult part of having an outside expert apply a pattern language is in fact to get a reliable, complete list of the problems to be solved. Of course, the people most familiar with the problems are the people that need a design. So, Alexander famously advocated on-site improvisation by concerned, empowered users,Alexander, Christopher, The Oregon Project as a powerful way to form very workable large-scale initial solutions, maximizing the utility of a design, and minimizing the design rework. The desire to empower users of architecture was, in fact, what led Alexander to undertake a pattern language project for architecture in the first place.
The range of situations in which the problems and solutions addressed in a pattern apply is called its context. An important part in each pattern is to describe this context. Examples can further illustrate how the pattern applies to very different situation.
For instance, Alexander's pattern "A PLACE TO WAIT" addresses bus stops in the same way as waiting rooms in a surgery, while still proposing helpful and constructive solutions. The Design Patterns/" itemprop="url" title="Wiki: Design Patterns">Design Patterns by Gamma et al. proposes solutions that are independent of the programming language, and the program's application domain.
Still, the problems and solutions described in a pattern can vary in their level of abstraction and generality on the one side, and specificity on the other side. In the end this depends on the author's preferences. However, even a very abstract pattern will usually contain examples that are, by nature, absolutely concrete and specific.
Patterns can also vary in how far they are proven in the real world. Alexander gives each pattern a rating by zero, one or two stars, indicating how well they are proven in real-world examples. It is generally claimed that all patterns need at least some existing real-world examples. It is, however, conceivable to document yet unimplemented ideas in a pattern-like format.
The patterns in Alexander's book also vary in their level of scale – some describing how to build a town or neighbourhood, others dealing with individual buildings and the interior of rooms. Alexander sees the low-scale artifacts as constructive elements of the large-scale world, so they can be connected to a hierarchic network.
Often these problems arise from a conflict of different interests or "forces". A pattern emerges as a dialogue that will then help to balance the forces and finally make a decision.
For instance, there could be a pattern suggesting a wireless telephone. The forces would be the need to communicate, and the need to get other things done at the same time (cooking, inspecting the bookshelf). A very specific pattern would be just "WIRELESS TELEPHONE". More general patterns would be "WIRELESS DEVICE" or "SECONDARY ACTIVITY", suggesting that a secondary activity (such as talking on the phone, or inspecting the pockets of your jeans) should not interfere with other activities.
Though quite unspecific in its context, the forces in the "SECONDARY ACTIVITY" pattern are very similar to those in "WIRELESS TELEPHONE". Thus, the competing forces can be seen as part of the essence of a design concept expressed in a pattern.
More generally, we could say that a good system should be accepted, welcomed and happily embraced as an enrichment of daily life by those who are meant to use it, or – even better – by all people it affects. For instance, when discussing a street café, Alexander discusses the possible desires of a guest, but also mentions people who just walk by.
The same thinking can be applied to technical devices such as telephones and cars, to social structures like a team working on a project, or to the user interface of a computer program. The qualities of a software system, for instance, could be rated by observing whether users spend their time enjoying or struggling with the system.
By focusing on the impacts on human life, we can identify patterns that are independent from changing technology, and thus find "timeless quality" (Alexander).
Christopher Alexander's patterns, for instance, each consist of a short name, a rating (up to two '*' symbols), a sensitizing picture, the context description, the problem statement, a longer part of text with examples and explanations, a solution statement, a sketch and further references. This structure and layout is sometimes referred to as the "Alexandrian form".
Alexander uses a special text layout to mark the different sections of his patterns. For instance, the problem statement and the solution statement are printed in bold font, the latter is always preceded by the "Therefore:" keyword. Some authors instead use explicit labels, which creates some degree of redundancy.
In Alexander's book, such links are collected in the "references" part, and echoed in the linked pattern's "context" part – thus the overall structure is a directed graph. A pattern that is linked to in the "references" usually addresses a problem of lower scale, that is suggested as a part of the higher-scale problem. For instance, the "PUBLIC OUTDOOR ROOM" pattern has a reference to "STAIR SEATS".
Even without the pattern description, these links, along with meaningful names, carry a message: When building a place outside where people can spend time ("PUBLIC OUTDOOR ROOM"), consider to surround it by stairs where people can sit ("STAIR SEATS"). If you are planning an office ("WORKSHOPS AND OFFICES"), consider to arrange workspaces in small groups ("SMALL WORKING GROUPS"). Alexander argues that the connections in the network can be considered even more meaningful than the text of the patterns themselves.
The links in Alexander's book clearly result in a hierarchic network. Alexander draws a parallel to the hierarchy of a grammar – that is one argument for him to speak of a pattern language.
The idea of linking is generally accepted among pattern authors, though the semantic rationale behind the links may vary. Some authors, however, like Gamma et al. in Design Patterns, make only little use of pattern linking – possibly because it did not make that much sense for their collection of patterns. In such a case we would speak of a pattern catalogue rather than a pattern language.
It is important to note that notations such as UML or the flowchart symbol collection are not pattern languages. They could more closely be compared to an alphabet: their symbols could be used to document a pattern language, but they are not a language by themselves. A recipe or other sequential set of steps to be followed, with only one correct path from start to finish, is also not a pattern language. However, the process of designing a new recipe might benefit from the use of a pattern language.
The framework and philosophy of the "pattern language" approach was initially popularized in the book A Pattern Language that was written by Christopher Alexander and five colleagues at the Center for Environmental Structure in Berkeley, California in the late 1970s. While A Pattern Language contains 253 "patterns" from the first pattern, "Independent Regions" (the most general) to the last, "Things from Your Life", Alexander's book The Timeless Way of Building goes into more depth about the motivation and purpose of the work. The following definitions of "pattern" and "pattern language" are paraphrased from A Pattern Language:
"A pattern is a careful description of a perennial solution to a recurring problem within a building context, describing one of the configurations that brings life to a building. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core solution to that problem, in such a way that you can use the solution a million times over, without ever doing it the same way twice."
A pattern language is a network of patterns that call upon one another. Patterns help us remember insights and knowledge about design and can be used in combination to create solutions.
Ward Cunningham, the inventor of wiki, coauthored a paper with Michael Mehaffy arguing that there are deep relationships between wikis and pattern languages, and that wikis "were in fact developed as tools to facilitate efficient sharing and modifying of patterns".
|
|